
United States Patent and Trademark Office 



UNITED STATES DEPARTMENT OF COMMERCE 
United States Patent and Trademark Office 
Address: COMMISSIONER FOR PATENTS 
P.O. Box 1450 

Alexandria, Virginia 223 1 3- 1450 
www.uspto.gov 



APPLICATION NO. 


FILING DATE 


FIRST NAMED INVENTOR 


ATTORNEY DOCKET NO. 


CONFIRMATION NO. 


09/500.391 


02/08/2000 


Wei-Ping Sun 


CISCO-1858 


2543 



7590 

David B Ritchie 
D'Alessandra & Ritchie 
P O Box 640640 
San Jose, CA 95164 



06/14/2005 



EXAMINER 



NGUYEN, STEVEN H D 



ART UNIT 



PAPER NUMBER 



2665 

DATE MAILED: 06/14/2005 



Please find below and/or attached an Office communication conceming this application or proceeding. 



PTO 90C (Rev 10/03) 



Office Action Summary 


Application No. 

09/500,391 


Applicant(s) 

SUN ET AL. 


cxaminBr 

Steven HD Nguyen 


Art Unit 

2665 





The MAILING DATE of this communication appears on the cover sheet with the correspondence address -• 



Period for Reply 

A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) FROM 
THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time nnay be available under the provisions of 37 CFR 1 . 1 36(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If the period for reply specified atKJve is less than thirty (30) days, a reply within the statutory minimum of thirty (30) days will be considered timely. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 1 33). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1 .704(b). 

Status 

1 )K Responsive to Gommunication{s) filed on 31 March 2005 . 
2a)n This action is FINAL. 2b)^ This action is non-final. 

3) 0 Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 11, 453 O.G. 213. 

Disposition of Claims 

4) K Claim(s) 1-4,6-8, 10-17,37 and 39-48 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) 0 Claim(s) is/are allowed. 

6) K Claim(s) 1-4, 6-8. 10-17. 37 and 39-48 is/are reiected. 

7) 0 Claim(s) is/are objected to. 

8) [3 Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) 0 The specification is objected to by the Examiner. 

10)0 The drawing(s) filed on is/are: a)0 accepted or b)0 objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 

Replacement drawing sheet(s) including the correction is required if the drawing(s) Is objected to. See 37 CFR 1.121(d). 
1 1 )0 The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-1 52. 

Priority under 35 U.S.C, § 119 

12)0 Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 
a)0 All b)D Some * c)0 None of: 

1 .0 Certified copies of the priority documents have been received. 

2.D Certified copies of the priority documents have been received in Application No, . 

3.0 Copies of the certified copies of the priority documents have been received in this National Stage 
application from the international Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 



Attach ment(s) 

1) O Notice of References Cited (PTO-892) 4) O Interview Summary (PTO-413) 

2) O Notice of Draftsperson's Patent Drawing Review (PTO-948) Paper No(s)/Mail Date. . 

3) O Information Disclosure Statement(s) (PTO-1449 or PTO/SB/08) 5) O Notice of Infomial Patent Application (PTO-1 52) 

Paper No(s)/Mail Date . 6) O Other: . 



U.S. Patent and Trademark Office 
PTOL-326 {Rev. 1-04) 



Office Action Summary 



Part of Paper No./Mail Date 060905 



Application/Control Number: 09/500,39 1 Page 2 

Art Unit: 2665 

DETAILED ACTION 
Continued Examination Under 37 CFR LI 14 

1. A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is 
eUgible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.114. Apphcant's submission filed on 6/10/05 has been entered. 

Claim Rejections - 35 USC § 112 

2. The following is a quotation of the first paragraph of 35 U.S.C. 112: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention, 

3. Claims 1-4, 5-8, 10-17, 37, 39-48 rejected under 35 U.S.C. 1 12, first paragraph, as failing 
to comply with the written description requirement. The claim(s) contains subject matter which 
was not described in the specification in such a way as to reasonably convey to one skilled in the 
relevant art that the inventor(s), at the time the appHcation was filed, had possession of the 
claimed invention. As claims 1, 16, 37, 41, 43, 46, the recitation " the request packet not 
containing an unique identifier for the router card. In the specification, page 10, lines 1-6, the 
request packet includes the port address of the router card" which is used to identify the router 
card. Also, see claims 11, 12, 44, 47. 
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Claim Rejections ' 35 use § 103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

5. Claims 1-4, 6-8, 10-17, 37 and 39-48 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Hansen (US Pat. 6772204) in view of K. R. Soilings, (TFTP Protocol 
(Revision 2) (hereinaher RFC 783), and Bailey et al. (US 6,185,623). 

Regarding claims 1, 16, 37, 41, 43 and 46, Hansen discloses a method and system for 
downloading configxiration file to a network device (Fig lb, Ref 26) which couples to the 
network management server. A network configuration tool "system controller" (Fig lb, Ref 10, 
28, 30 and 32) for receiving a request packet "Bootp packets" via network "bus" (col. 16, lines 
13-26, Fig lb, 29b) wherein the bootp request packet contains a destination address of a network 
device that contain configuration tool and address of the network device that send a request 
including code "file type" wherein the code contains port address (See col. 7, lines 40-52, PCI 
slot read on port address), "the request packet not identified the imique identifier of the card such 
Ethernet, X.25, Frame relay etc, and not includes a file name", the network configuration tool 
examines the bootp packet based on the destination address and code and retrieving the file name 
for transmitting to the network device via a reply message, then the network device send a new 
request for downloading the file by using a trivial file transfer protocol (TFTP). The TFTP server 
locates and opens this file based on the information provided in the TFTP request, then 
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downloads this boot file to the network device based on the protocol that uses to transmit the 
packet "packet size" (See col. 16, lines 27-38 and col. 17, lines 8-38). However, Hansen fails to 
discloses file size, the ack, duplicating ack, opcode, block number, checksum of packet, active 
and inactive router, hi the same field of endeavor, RFC 783 discloses a format for TFTP packets 
that demonstrates a TFTP request packet containing a source port address and destination 
address in the request packet and ack packet and transmitting or retransmitting the packets 
contains the requested file between the devices (Pages 8-13). However, Hansen and RFC 783 
fails to disclose a file size, master "active", slave "inactive" and determining the memory for 
storing the file. In the same field of endeavor, Bailey discloses a system for booting a client 
computer fi-om a server that uses the TFTP. In this system the client may include a transfer size 
request in the TFTP request packet, in which case the server responds to the request packet with 
the transfer size (col. 4, line 58 - col. 5, line 36). The purpose of requesting the transfer size is to 
determine the amount of memory needed to store a file (col. 1 1, lines 57-67). This constitutes 
setting up a buffer size of at least as large as the file size. Bailey also discloses a subnet group of 
clients wherein one client is the master client, representing the active router card of the present 
invention, while any other clients in the group represent an inactive router cards (col. 6, lines 25- 
40 and col. 7, lines 35-56). 

Since, the references suggest the use TFTP for transferring the packet between the 
devices. Therefore, it would have been obvious to one of ordinary skill in the art to apply a 
method of send the file size and file names to the MC so that the network device would be able 
to set aside enough memory to store the image file. One of ordinary skill in the art would have 
been motivated to have a group of chents containing a master client in case the group of clients 
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all needed to download the same image file in order to use a common operating system as 
disclosed by Bailey's system and method into RFC 783 which teaches a method and system for 
transmitting a file between the device using TFTP into a method and system of Hansen. The 
motivation would have been to prevent error during the configuration of the network device and 
reduce the cost of device. 

Regarding claims 2 and 17, Hansen discloses using trivial file transfer protocol (TFTP) 
to make the request for the image file (Col. 17, lines 15-30). Hansen fails to expressly disclose 
forming a data packet from the file, wherein the data packet is a fixed size and includes a system 
frame header and a data packet protocol header. RFC 783 discloses that TFTP uses packets of 
fixed length blocks (page 3). Figure 3-1; Order of Headers (page 5) shows a header structure 
including Local Medium and Intemet headers, which collectively represent the system frame 
header of the present invention, and Datagram and TFTP headers, which represent the data 
packet protocol header of the present invention. TFTP also specifies that each data packet must 
be acknowledged by an acknowledgement packet before the next packet can be sent (page 3). At 
the time the invention was made, it would have been obvious to a person of ordinary skill in the 
art to use the fixed size TFTP packet format with the appropriate headers in sending data packets 
formed from the requested file. One of ordinary skill in the art would have been motivated to do 
this because this protocol is small and easy to implement for the purpose of transferring files. 

Regarding claim 3, Hansen fails to disclose sending a last packet less than the fixed size. 
RFC 783 discloses that a data packet of less than 512 bytes, which is the fixed size, signals 
the termination of a transfer (page 3). At the time the invention was made, it would have been 
obvious to a person of ordinary skill in the art to use this last packet smaller that 512 bytes at the 
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end of the file transfer as disclosed by RFC 783 into Hansen's system. One of ordinary skill in 
the art would have been motivated to do this to reduce the processing time at the receiving node. 

Regarding claim 4, Hansen fails to disclose retransmitting a data packet to the client if 
the server receives a duplicate acknowledgment packet for the previous packet. RFC 783 
discloses that a lost data packet causes a timeout for the intended recipient, in which case the 
intended recipient retransmits its last packet (page 3). Thus, if the intended recipient is the client 
and a timeout condition occurs, the client would then send an acknowledgement packet for the 
previously received data packet, i.e. a duplicate acknowledgment. At the time the invention was 
made, it would have been obvious to a person of ordinary skill in the art to retransmit a data 
packet formed fi"om the image file in response to receiving a duplicate acknowledgement packet. 
One of ordinary skill in the art would have been motivated to do this in order to signal the server 
that a data packet has not been received and needs to be retransmitted and reducing the 
congestion at the network. 

Regarding claims 6, 40, 45 and 48, Hansen does not expressly disclose a system fi-ame 
header and a data packet protocol header consisting essentially of an operation code, a block 
number, a file type and a checksum. RFC 783 discloses a header structure in Figure 3-1; Order 
of Headers (page 5) of Local Medium and Intemet headers, which represent the system fi-ame 
header of the present invention, and the Datagram and TFTP headers represent the data packet 
protocol header of the present invention. The format for a data packet includes an opcode and a 
block # (see Figure 5-2, page 10). Additionally, TFTP specifies that it may be implemented on 
top of the Internet User Datagram Protocol (UDP or Datagram) (page 2). The User Datagram 
Header includes a checksum (page 15). Thus, this checksum would be included in the data 
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packet protocol header. RFC 783 also specifies that a request (RRQ) packet includes a filename 
in the header. It would have been obvious to a person of ordinary skill in the art to use a system 
frame header and the data packet protocol header format of a TFTP data packet in sending data 
packets and include opcode, block number, check sum, in the header of the data packet as 
disclosed by RFC 783 into the system of Hansen. 

Regarding claim 7, Hansen fails to disclose that the acknowledgement packet consists 
essentially of a system frame header, and acknowledgement code, and a block number. RFC 783 
discloses a format for an ACK packet that contains an opcode, which represents the 
acknowledgement code, and block # (see Figure 5-3, page 10). The system frame header is 
shown in Figure 3-1 (page 5). At the time the invention was made, it would have been obvious 
to a person of ordinary skill in the art to use this format of an acknowledgement packet in 
acknowledging the received file from the server as disclosed by RFC 783 into system of Hansen. 
One of ordinary skill in the art would have been motivated to do this so that the server would 
know which packets have been sent successfully and which ones need to be retransmitted. 

Regarding claims 8 and 10, Hansen discloses a media access control (MAC) address of 
the MC that is 12 characters long in hexadecimal format, or 6 bytes long if represented in binary 
(col. 16, line 13-26) and destination also has a MAC address. Hansen fails to disclose a system 
frame header that specifies the addresses of the router card and system controller. RFC 783 
discloses a system frame header composed of Local Medium and Intemet headers (Figure 3-1, 
page 5). At the time the invention was made, it would have been obvious to send includes the 
addresses in the packet as disclosed RFC 783 into Hansen's system. One of ordinaly skill in the 
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art would have been motivated to do this so that the packet would be routed to the correction 
destination NIC and that the receiving NIC was sure that this packet was coming from the server. 

Regarding claims 11, 12, 39, 42, 44 and 47, Hansen discloses a media access control 
(MAC) address of the MC that is 12 characters long in hexadecimal format, or 6 bytes long if 
represented in binary (col. 16, line 13-26) and destination also has a MAC address. Hansen fails 
to disclose a system frame header that specifies the addresses of the router card and system 
controller, a request code, and a file type in the request packet. RFC 783 discloses a system 
frame header composed of Local Medium and Intemet headers (Figure 3-1, page 5). RFC 783 
also discloses a request packet format that includes an opcode, which is the request code of the 
present invention, and a filename, which represents the file type of the present invention (see 
Figure 5-1, page 8). At the time the invention was made, it would have been obvious to apply 
addresses frame header, a request code as disclosed by RFC 783 into Hansen's system. One of 
ordinary skill in the art would have been motivated to do this so that the packet would be routed 
to the correction destination MC and that the receiving MC was sure that this packet was coming 
from the server. 

Regarding claims 13-15, Hansen discloses power up a network device (Col. 16, lines 13- 

26). 

Response to Arguments 
6. Applicant's arguments filed 3/3 1/05 have been fiiUy considered but they are not 
persuasive. 
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In response to pages 13-16, the applicant states that the limitation "the request packet 
does not contain an unique identifier for the router card" is inherently disclosed by the 
specification because the invention does not need to identify the router card when transmits the 
request packet because it's use the port address of the router card and file type to identify the file 
which it needs to retrieve.. In reply, the specification is not inherently disclose this limitation 
because if the request packet includes an unique identifier and port address of the router card and 
file type, the router card still received the file which it is received because the storage contains 
plurality of files for using to setup the device. Therefore, the rejection maintains because the 
specification does not inherently exclude this limitation fi-om the request packet. 
7. In response to applicant's argument of pages 14-16 that the examiner's conclusion of 
obviousness is based upon improper hindsight reasoning, it must be recognized that any 
judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight 
reasoning. But so long as it takes into account only knowledge which was within the level of 
ordinary skill at the time the claimed invention was made, and does not include knowledge 
gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re 
McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971). 

In response to applicant's argument of pages 14-16 that there is no suggestion to combine 
the references, the examiner recognizes that obviousness can only be established by combining 
or modifying the teachings of the prior art to produce the claimed invention where there is some 
teaching, suggestion, or motivation to do so found either in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 
5 USPQ2d 1596 (Fed. Cir. 1988)and//z re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 
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1992). In this case, Hansen discloses a method and system for generating a request packet that 
contains file type and a number unique to a particular device type such Cisco or Compaq router 
and module number "it is not an unique identifier for identifying one device of plurality of 
devices of a particular device type (such Ethernet having it module number and unique number 
for identifying Ethemet type reads on particular device type) and using TFTP for retrieving the 
file based on file type request and PCI slot "port address" and RFCE 783 discloses a method and 
system for using TFTP for retrieving the file and Bailey discloses a method and system for using 
TFTP for transmitting the packets and activated the standby client if the master client fails. 
These references use the same protocol to transmit a file between the server and client. 
Therefore, it would have been obvious to one of ordinary skill in the art to combine these 
teaching into one system. The motivation would have been to prevent error during the 
configuration of the network device and reduce the cost of device. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Steven HD Nguyen whose telephone number is (571) 272-3159. 
The examiner can normally be reached on 8-5. 

If attempts to reach the examiner by telephone are unsuccessfiil, the examiner's 
supervisor, Huy D. Vu can be reached on (571) 272-3155. The fax phone number for the 
organization where this apphcafion or proceeding is assigned is 703-872-9306. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-2 1 7-9 1 97 (toll-free). 
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